<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" xml:lang="en" lang="en">
<!-- Created by GNU Texinfo 5.1, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Structure and Interpretation of Computer Programs, 2e: Preface 1e</title>

<meta name="description" content="Structure and Interpretation of Computer Programs, 2e: Preface 1e" />
<meta name="keywords" content="Structure and Interpretation of Computer Programs, 2e: Preface 1e" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Generator" content="texi2any" />
<meta charset="utf-8" />
<link href="index.xhtml#Top" rel="start" title="Top" />
<link href="Term-Index.xhtml#Term-Index" rel="index" title="Term Index" />
<link href="index.xhtml#SEC_Contents" rel="contents" title="Table of Contents" />
<link href="index.xhtml#Top" rel="prev" title="Top" />
<link href="Acknowledgments.xhtml#Acknowledgments" rel="next" title="Acknowledgments" />
<link href="Preface.xhtml#Preface" rel="prev" title="Preface" />

<link href="css/style.css" rel="stylesheet" type="text/css" />
<link href="css/prettify.css" rel="stylesheet" type="text/css" />
</head>

<body>
<section><span class="top jump" title="Jump to top"><a href="#pagetop" accesskey="t">⇡</a></span><a id="pagetop"></a><a id="Preface-1e"></a>
<nav class="header">
<p>
Next: <a href="Acknowledgments.xhtml#Acknowledgments" accesskey="n" rel="next">Acknowledgments</a>, Prev: <a href="Preface.xhtml#Preface" accesskey="p" rel="prev">Preface</a>, Up: <a href="index.xhtml#Top" accesskey="u" rel="prev">Top</a>   [<a href="index.xhtml#SEC_Contents" title="Table of contents" accesskey="c" rel="contents">Contents</a>]</p>
</nav>
<a id="Preface-to-the-First-Edition"></a>
<h2 class="unnumbered">Preface to the First Edition</h2>

<blockquote>
<p>A computer is like a violin.  You can imagine a novice trying first a
phonograph and then a violin.  The latter, he says, sounds terrible.  That is
the argument we have heard from our humanists and most of our computer
scientists.  Computer programs are good, they say, for particular purposes, but
they aren’t flexible.  Neither is a violin, or a typewriter, until you learn
how to use it.
</p>
<p>—Marvin Minsky, <cite>Why Programming Is a Good Medium for Expressing
Poorly-Understood and Sloppily-Formulated Ideas</cite>
</p></blockquote>


<p>“The Structure and Interpretation of Computer Programs” is the entry-level
subject in computer science at the Massachusetts Institute of Technology.  It
is required of all students at <abbr>MIT</abbr> who major in electrical
engineering or in computer science, as one-fourth of the “common core
curriculum,” which also includes two subjects on circuits and linear systems
and a subject on the design of digital systems.  We have been involved in the
development of this subject since 1978, and we have taught this material in its
present form since the fall of 1980 to between 600 and 700 students each year.
Most of these students have had little or no prior formal training in
computation, although many have played with computers a bit and a few have had
extensive programming or hardware-design experience.
</p>
<p>Our design of this introductory computer-science subject reflects two major
concerns.  First, we want to establish the idea that a computer language is not
just a way of getting a computer to perform operations but rather that it is a
novel formal medium for expressing ideas about methodology.  Thus, programs
must be written for people to read, and only incidentally for machines to
execute.  Second, we believe that the essential material to be addressed by a
subject at this level is not the syntax of particular programming-language
constructs, nor clever algorithms for computing particular functions
efficiently, nor even the mathematical analysis of algorithms and the
foundations of computing, but rather the techniques used to control the
intellectual complexity of large software systems.
</p>
<p>Our goal is that students who complete this subject should have a good feel for
the elements of style and the aesthetics of programming.  They should have
command of the major techniques for controlling complexity in a large
system. They should be capable of reading a 50-page-long program, if it is
written in an exemplary style. They should know what not to read, and what they
need not understand at any moment.  They should feel secure about modifying a
program, retaining the spirit and style of the original author.
</p>
<p>These skills are by no means unique to computer programming.  The techniques we
teach and draw upon are common to all of engineering design.  We control
complexity by building abstractions that hide details when appropriate.  We
control complexity by establishing conventional interfaces that enable us to
construct systems by combining standard, well-understood pieces in a “mix and
match” way.  We control complexity by establishing new languages for
describing a design, each of which emphasizes particular aspects of the design
and deemphasizes others.
</p>
<p>Underlying our approach to this subject is our conviction that “computer
science” is not a science and that its significance has little to do with
computers.  The computer revolution is a revolution in the way we think and in
the way we express what we think.  The essence of this change is the emergence
of what might best be called <a id="index-procedural-epistemology"></a>
<em>procedural epistemology</em>—the study of
the structure of knowledge from an imperative point of view, as opposed to the
more declarative point of view taken by classical mathematical subjects.
Mathematics provides a framework for dealing precisely with notions of “what
is.”  Computation provides a framework for dealing precisely with notions of
“how to.”
</p>
<p>In teaching our material we use a dialect of the programming language Lisp.  We
never formally teach the language, because we don’t have to.  We just use it,
and students pick it up in a few days.  This is one great advantage of
Lisp-like languages: They have very few ways of forming compound expressions,
and almost no syntactic structure.  All of the formal properties can be covered
in an hour, like the rules of chess.  After a short time we forget about
syntactic details of the language (because there are none) and get on with the
real issues—figuring out what we want to compute, how we will decompose
problems into manageable parts, and how we will work on the parts.  Another
advantage of Lisp is that it supports (but does not enforce) more of the
large-scale strategies for modular decomposition of programs than any other
language we know.  We can make procedural and data abstractions, we can use
higher-order functions to capture common patterns of usage, we can model local
state using assignment and data mutation, we can link parts of a program with
streams and delayed evaluation, and we can easily implement embedded languages.
All of this is embedded in an interactive environment with excellent support
for incremental program design, construction, testing, and debugging.  We thank
all the generations of Lisp wizards, starting with John McCarthy, who have
fashioned a fine tool of unprecedented power and elegance.
</p>
<p>Scheme, the dialect of Lisp that we use, is an attempt to bring together the
power and elegance of Lisp and Algol.  From Lisp we take the metalinguistic
power that derives from the simple syntax, the uniform representation of
programs as data objects, and the garbage-collected heap-allocated data.  From
Algol we take lexical scoping and block structure, which are gifts from the
pioneers of programming-language design who were on the Algol committee.  We
wish to cite John Reynolds and Peter Landin for their insights into the
relationship of Church’s λ-calculus to the structure of programming
languages.  We also recognize our debt to the mathematicians who scouted out
this territory decades before computers appeared on the scene.  These pioneers
include Alonzo Church, Barkley Rosser, Stephen Kleene, and Haskell Curry.
</p>
<nav class="header">
<p>
Next: <a href="Acknowledgments.xhtml#Acknowledgments" accesskey="n" rel="next">Acknowledgments</a>, Prev: <a href="Preface.xhtml#Preface" accesskey="p" rel="prev">Preface</a>, Up: <a href="index.xhtml#Top" accesskey="u" rel="prev">Top</a>   [<a href="index.xhtml#SEC_Contents" title="Table of contents" accesskey="c" rel="contents">Contents</a>]</p>
</nav>


</section><span class="bottom jump" title="Jump to bottom"><a href="#pagebottom" accesskey="b">⇣</a></span><a id="pagebottom"></a>
</body>
</html>